An enterprise with geographically distributed sites can implement a private network by utilizing a virtual private network (VPN) service from a service provider (also known as a communications carrier or communications provider) as an alternative to using leased lines to interconnect the various sites. A service provider can deploy such a VPN service using a variety of technologies and techniques, and can offer both Layer 2 and Layer 3 connectivity, using Layer 2 connections or Layer 2/3 tunnels. Examples of technologies to supply such VPN services are Frame Relay (FR) connections, Asynchronous Transfer Mode (ATM) connections, Ethernet tunnels, IP-based tunnels, MPLS, etc. Refer to RFC 3809, “Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN), June 2004, The Internet Society, the contents of which are incorporated herein by reference. U.S. Pat. No. 6,339,595, the contents of which are incorporated herein by reference, outlines a peer-model support for virtual private networks with potentially overlapping addresses. A similar technique is described in RFC 2547, “BGP/MPLS VPNs”, March 1999, The Internet Society, the contents of which are incorporated herein by reference. These techniques allow a service provider to offer VPN service to a plurality of enterprises or organizations over a shared network infrastructure.
In the existing VPN prior art, the service provider is providing connectivity between the sites of a given VPN, either at Layer 2 or Layer 3. For example, the service provider may provide Frame Relay or ATM connectivity between sites; provide a virtual time-division multiplexed network, provide a virtual private LAN service, or provide an IP VPN. The user of the VPN, such as an enterprise, then deploys various communication and application equipment at each site connected to or using the VPN, such as customer-edge (CE) routers, firewalls, load balancers, and application servers, message-oriented middleware, etc. Each enterprise has its own set of equipment and applications to utilize its own VPN network.
Service providers are increasingly moving applications into their core data networks to offer value-added functions or services above simple bandwidth, LAN or IP connectivity between sites (including providing optional access from a VPN to the public Internet). An example of such a service is a hosted message routing service (which may utilize content-based routing), XML firewall, XML load balancing, etc. Such services could be provided over the public internet (example being hosted email or hosted web sites), but when the service provider wishes to provide value-added services within the VPN of each customer, then the solution must be able to operate in the presence of private IP addresses, since they are typically used within the VPNs of enterprises or organizations.
It is desirable to use a common infrastructure to provide such value-added services. However, if a common infrastructure is to support multiple different customers in different VPNs simultaneously, then it has to be able to support overlapping IP addresses, since different organizations are free to use the same range of private IP addresses for their own internal use.
One method to get around overlapping IP addresses is to use Network Address Translation (NAT) devices to translate private addresses into unique public addresses. For a description of NAT, refer to “Traditional IP Network Address Translator (Traditional NAT)”, January 2001, The Internet Society, the contents of which are incorporated herein by reference. However, there are a number of issues with NAT: it does not function in all situations, such as fragmentation; it requires more infrastructure to install and manage, and if connection establishment is needed in both directions, static configuration tables are needed to allow external devices to connect into the private address realm.
Additionally, equipment to carry out functions such as message routing, XML firewalls, XML load balancers etc. typically handle one customer instance. Thus, for a service provider to support multiple customers via IP VPNs for such services, it would require a NAT per IP VPN or a separate device for the application per IP VPN. Note that the NAT and the application could be combined into a single device, but the result is still a plurality of devices to support multiple VPNs. Also, a significant limitation of the NAT solution is that if the application is to initiate a TCP connection into the VPN, then special pre-configured mappings are required on the NAT to statically provisioned IP addresses on the end devices. This limitation is not reasonable in practice.
Also required is the ability for the various customers using separate IP VPNs to share common information or to be able to interact with each other through an application such as message routing. For example, a service provider may wish to provide a shared set of information, such as real-time streaming stock quotes, into applications residing in different IP VPNs. A technique to allow this to occur in a cost-effective, secure and easy to manage manner is also required. Another example of such connectivity is the creation of “Community of Interest Networks” (COINs) where applications from different enterprises must communicate with each other over a common network to fulfill various functions such as negotiation and execution of certain financial transactions, for example.
Content-based networks are described in A Carzaniga, M. J. Rutherford, A. L. Wolf, A routing scheme for content-based networking, Department of Computer Science, University of Colorado, June 2003, the contents of which are incorporated herein by reference. In content routed networks, a publish/subscribe data communication is provided; wherein publishers can inject content into the network, and subscribers can subscribe to content from the network. The publishers and subscribers do not require knowledge of each other. Such networks can also provide point-to-point message communication, queue-based communication, and topic-based publish/subscribe communications.